Many world wide web (“Web”) applications allow the installation and use of custom third-party applications that extend the capabilities of the Web application. These third-party applications typically execute, from a permissions perspective, as the current user of the Web application. As a result, such third-party applications can typically perform any action that the current user could perform, typically within some restricted boundaries set for an application executing in conjunction with the Web application. This requires that the system administrator who installs the third-party application place significant trust in the application since the application can read, modify, or delete any information in the Web application that any of the application's user have access to.
One solution to the problem described above is to limit access by third-party applications to only certain functionality provided by a Web application. For instance, a third-party application may only be given access to certain capabilities of a Web application by limiting the application programming interfaces (“APIs”) exposed to the application. Another approach to the problem described above is to limit the scope of the trust decision made by the system administrator that installs the application. For example, environments within a Web application may be isolated from one another so that third-party applications can be installed, in separate environments without risk of corrupting other environments. This solution might be utilized, for instance, to limit an application's access to an environment that exposes sensitive data. This solution, however, is severely limiting given the fact that one of the most common reasons to utilize third-party applications is to aggregate data across different environments. Consequently, applications that apply to all of a company's environments across a Web application deployment are difficult or impossible to install in this scenario.
As mentioned above, third-party applications typically execute, from a permissions perspective, as the current user of the Web application. This means that the applications can only perform actions that their users have permission to perform. In many situations, however, it is desirable to allow a user or group of users, through the use of an application, to perform an action that their permissions would not permit them to perform directly. For example, an expense reporting application might approve an expense report when certain conditions are met (e.g., a small value), but a user should not have permission to approve the expense report directly without performing the operation through the application. This type of operation is not possible when the application executes as the current user. Some systems address this limitation by allowing applications to elevate permissions to a system account, which has no permission restrictions within the system. This solution, however, may make system administrators even more unwilling to install applications in environments that expose sensitive information.
It is with respect to these and other considerations that the disclosure made herein is presented.